In communication networks, such as telecommunication networks, a call or a service often involves, on the one hand, a control plane or signalling plane and, on the other hand, a user plane or a media plane. The control plane or signalling plane is in charge of establishing and managing a connection between two points of the network. The user plane or media plane is in charge of transporting user data or service data. Network operators have the desire to define and enforce a set of rules in the network. A set of rules constitutes policies. A policy framework for managing and enforcing these policies usually includes at least three elements or functions: a policy repository for storing policy rules, which may be user specific, a policy decision element or function and a policy enforcement element or function. The purpose of a policy framework includes controlling subscriber access to networks and services as well as the kind of access, i.e. its characteristics.
A policy framework notably addresses the decision as to whether the subscriber is entitled, or authorized, to enjoy a service, and whether the network can provide the service to the subscriber, and particularly whether the network can provide the service to the subscriber with a desired Quality of Service (QoS).
Policy and charging control architectures, such as, but not limited to, the architecture described in 3GPP TS 23.203 version 11.1.0 (2011-03), Technical Specification Group Services and System Aspects; Policy and charging control architecture (release 11) (available on http://www.3gpp.org/ftp/Specs/2011-03/Rel-11/23_series/), integrate policy and charging control. The Policy and Charging Control (PCC) architecture permits to integrate both policy and charging control. One aim of a policy framework is to set up and enforce rules dependent on subscribers and/or desired services to ensure efficient usage of network resources among all subscribers.
An architecture that supports Policy and Charging Control (PCC) functionality is depicted in FIG. 1 which is taken from 3GPP TS 23.203 specifying the PCC functionality for Evolved 3GPP Packet Switched domain including both 3GPP accesses and Non-3GPP accesses. The Policy Control and Charging Rules Function (PCRF) 110 is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding Service Data Flow (SDF) detection, gating, QoS and flow based charging (except credit management) towards the Policy and Charging Enforcement Function (PCEF) 120. The PCRF receives session and media related information from the Application Function (AF) 140 and informs the AF of traffic plane events. The PCRF 110 is also coupled to a Subscriber Profile Repository (SPR) 150.
The PCRF shall provision PCC Rules to the PCEF via the Gx reference point and may provision QoS Rules to the Bearer Binding and Event Reporting Function (BBERF) 130 via the S7x reference point.
In the architecture 100 of FIG. 1, the PCRF shall inform the PCEF through the use of PCC rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decision(s).
For example, the PCRF informs the PCEF through the use of PCC rules how to control the radio resources of the telecommunications network, where AP packets constituting traffic in a network can be assigned to bearer resources.
The Gx reference point or interface is defined in 3GPP TS 29.212 “Policy and charging control over Gx reference point”, and lies between the PCRF and the PCEF. The reference point is used for provisioning and removal of FCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both.
The Rx reference point is defined in 3GPP TS 29.214 “Policy and charging control over Rx reference point” and is used to exchange application level session information between the PCRF and the AF. An example of PCRF is the Ericsson Service-Aware Policy Controller (SAPC), see for example F. Castro et al., “SAPC: Ericsson's Convergent Policy Controller”, Ericsson review No. 1, 2010, pp. 4-9. An example of an AF is the IP Multi-Media Subsystem (IMS) Proxy Call Session Control Function (P-CSCF).
The Sd reference point in FIG. 1 may have a similar behaviour to the Rx reference point, which is seen in the following in which the AF and the TDF, at least for the purpose described in this application, can be used basically interchangeably.
Both Gx and Rx reference points may be based on Diameter, see for example P. Calhoun et al., “RFC 3588: Diameter Based Protocol”, IETF, September 2003.
The PCEF enforces policy decisions received from the PCRF and also provides the PCRF with user-and access-specific information over the Gx reference point, The node including the PCEF or another Bearer Binding Function (BBF) encompasses SOF detection based on filter definitions included in the PCC rules, as well as online and offline charging interactions (not described here) and policy enforcement. The PCEF is usually the one handling bearers, it is where the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. This functional entity, i.e. the PCEF, is located at the gateway, e.g. in the Gateway GPRS Support Node (GGSN), in the GPRS case. For all cases where there is Proxy Mobile IP (PMIP) or Dual-Stack Mobile IP (DSMIP) in the core network, the bearer control is performed in the BBERF instead.
The Application Function (AF) 140 is an element offering applications in which service is delivered in a different layer, e.g. transport layer, from the one the service has been requested, e.g. signalling layer. The control of resources, such as, but not limited to, IP bearer resources, is performed according to what has been negotiated. One example of a network node including an AF 140 is the P-CSCF (Proxy-Call Session Control Function) of the IP Multi-Media (IM) Core Network (CN) subsystem. The AF 140 may communicate with the PCRF 110 to transfer dynamic session information, i.e. description of multi-media to be delivered in the transport layer. This communication is performed using the above-described Rx interface or Rx reference point, which is placed between the PCRF 110 and the AF 140 and is used to exchange application level information between the PCRF 110 and the AF 140. Information in the Rx interface may be derived from the session information or service session information in the P-CSCF and it mainly includes what is called media components. A media component is composed by a set of IP flows, each one described through a 5-tuple, the media type and bandwidth required, for example. Another example of a network node including an AF 140 is a streaming server.
The AF may interact or intervene with applications that require dynamic policy and charging control. It extracts service session information and provides this to the PCRF over the Rx reference point. The AF also can subscribe to certain events that occur at the traffic plane, i.e. events detected by either the PCRF or BBERF. Those traffic plane events include events such as IP session termination or access technology-type change.
The PCRF 110 may also contact the SPR 150 to obtain subscription data. The SPR may contain information about the subscriber and its policies. If a user is a “premium” subscriber and is permanently able to have bandwidths larger than the average user sessions of this user are connected with high QoS.
Upon reception of the PCC/QoS rule from the PCRF, Bearer Binding Function (BBF), either the PCEF or BBERF depending on the deployment scenario, performs bearer binding, i.e. associates the provided rule to an IP-CAN bearer within an IP-CAN (Internet Protocol Connectivity Access Network) session. The BBF will use the QoS parameters provided by the PCRF to create the bearer binding for the rule. The binding is created between service data flows included in the PCC/QoS rule and the IP-CAN bearer which have the same QoS Class Identifier (QCI) and Allocation Retention Priority (ARP).
Generally, the bearer binding function will evaluate whether it is possible to use one of the existing IP-CAN bearers or not. If none of the existing bearers can be used, the establishment of a suitable IP-CAN bearer is initiated. Otherwise, if required, e.g. QoS information has changed, the BBF will initiate the modification of a corresponding bearer. For GBR bearers, i.e. bearers with a guaranteed bit rate, the BBF will reserve the required resources based on the QoS information provided by the PCRF.
If the QCI and ARP of the PCC/QoS rule match the QCI and ARP of the default bearer, the BBF will install those rules in the default bearer. When the PCRF requests the removal of previously provided PCC/QoS rules, the BBF will delete them and modify the bearers accordingly. When all the PCC/QoS rules applied to one bearer have been deleted and/or deactivated, the BBF will start the bearer termination procedure.
Next, PCC support to applications is described. When an application requires dynamic policy and/or charging control over the IP-CAN user plane to start a service session, the AF communicates with the PCRF to transfer the dynamic session information required for the PCRF to take the appropriate actions on the IP-CAN network. The PCRF authorizes the session information, creates the corresponding PCC/QoS rules and installs them in the PCEF/BBERF. The applicable bearer will be initiated/modified and if required, resources will be reserved for that application.
Once the application or the user equipment (UE) decides to terminate the service, the AF communicates the PCRF so that the PCRF can remove the applicable PCC/QoS rules and the PCEF/BBERF stops the corresponding SDF detection, policy enforcement and flow based charging functionalities, terminating or updating the applicable bearer, and releasing the corresponding resources.
An application server running a service application and including the AF, such as a streaming server, may request establishment of a bearer for the PCRF according to its requirements, i.e. video or other streaming services requiring specific bandwidths, QoS, charging, etc.
Deep Packet inspection (DPI) technology supports packet inspection and service classification, which consists of IP-packets classified according to a configured tree of rules so that they are assigned to a particular service session. DPI is currently under standardization, as the so-called Traffic Detection Function (TDF), such as TDF 160, which can be either standalone or collocated with the PCEF (see FIGS. 12b and 12c), wherein traffic is captured by this function for packet inspection. The TDF 160 is a functional entity that performs application detection and reporting of detected application or service and its service data flow description to the PCRF. The TDF can act in solicited mode, i.e. upon request from the PCRF, or unsolicited mode, i.e. without any request from the PCRF. The data traffic captured by the TDF is usually IP-packet data. For details, it is referred to 3GPP TR 23.813.
Currently, most existing UEs, i.e. mobile devices, such as mobile phones or other devices with mobile communication capabilities such as tablet or laptop computers, do not have support for dedicated bearers. Thus, most traffic, i.e. data traffic of services the user is running, goes into the default bearer and it is not possible to assign different QoS for each service the user is running. However, in the future, it is expected that more service sessions of one or more services are mapped to dedicated bearers.
Using long-lived dedicated bearers, e.g. to boost the QoS for sponsored services, implies a high demand on network resources, especially when the dedicated bearers are triggered by the AF, e.g. Smart Pipe Controller (SPC) in Mobile Cloud Accelerator (MCA) solution.
The AF sessions remain active as long as the corresponding service is active. Some services/protocols like RTSP indicate the service stop condition in their own signaling (RTSP.TEARDOWN), but the majority of services, such as HTTP browsing, do not have such indication, so a service stop condition needs to be based on inactivity timers handled locally by the AF node. This is internal AF functionality not defined in 3GPP, but the external effect is that this event (service stop) is used to trigger the AF session termination. Those inactivity timers are usually set to very high values, e.g. on the order of tens or hundreds of minutes, mainly to reduce network signaling, i.e. to avoid ping pong effects generated when the timer is set to a low value, where detection of service inactivity triggers the release of the dedicated bearer, but after some time, some service packets are detected, so the dedicated bearer needs to be created again.
In order to reduce signaling, dedicated bearers are kept during a long time. Setting inactivity timers to very high values implies that the AF session remains active for a very long time, even if the user is not running the corresponding service anymore. Having the AF session active during long times has an impact on both AF and PCRF memory, which, for example, have to store up to a million or more session information entries of a large number of users. This can result in a waste of network resources, such as memory. Therefore, there is a desire to optimize network resources so as to reduce memory usage, for example.